1. Field of the Disclosure
The present disclosure relates generally to the field of computers and, more specifically, to a method and system of visually developing distributed applications without programming.
2. Description of the Background
A computers, as in FIG. 1, comprises a digital processor 41 that executes instructions to perform tasks. The illustrated computer further includes input devises (mouse 44 and keyboard 45), a display 46, and a modem 47. These components are connected to a memory 51 via a local interface 43. The memory 51 holds an operating system 52, a window manager 53, and a computer program 100. A collection of instructions, or machine code, is referred to as a computer program. Programs can be manifested in a variety of forms, such as but not limited to stand-alone Executables, Libraries, Dynamic Link Libraries, Drivers, Components, Objects, and Distributed Objects.
Programs are created from instructions of a programming language that are accumulated into the program's source code. The source code controls presentation, interfaces, and logic. A programmer authors source-code and compiles it into processor machine code utilizing a compiler compatible with both the source code's language and target processor.
Some programs have an interface that allows other external programs to interact with the program during run-time execution. The interface to Executables, Libraries, and Drivers is typically called an Application Programming Interface or API, while the interface to Components, Objects, and Distributed Objects is simply called an interface. Despite some functional differences, each provides a mechanism for a programmer to interact with a program.
Regardless of the program, its interface will be comprised of one or more of the following primitives: (1) Parameter or Property of a fundamental data type, or (2) Function or Method, which further has an optional list of fundamental data types.
Applications are constructed from one or more programs. Programmers write source code leveraging interfaces that enable disparate programs to interact with each other and provide greater utility.
The process of writing source-code, compiling the source code into machine code, and debugging programs is incredibly costly and difficult. There are very few programmers relative to the general population, and very few highly skilled programmers relative to all programmers. Furthermore, there is little consistency between interfaces of disparate programs causing programmers to face long learning curves when implementing third-party programs in their applications.
To eliminate many of the problems associated with programming, there has been long standing goal in the field of software development to achieve the same level of “componentized” development as in the field of electronic circuit design. In 1968, Doug McIlroy presented a paper on Mass Produced Software Components. The following is a quote from this paper: “Follow the lead of hardware design! It is not right that every new development should start from scratch. There should be catalogs of software modules, as there are catalogs of VLSI devices: when we build a new system, we should be ordering components from these catalogs and combining them, rather than reinventing the wheel every time.”
To assure interoperability between devices, electronic circuit design industry standards emerged in the form of “Logic Families” such as TTL or CMOS. A logic family defines strict operating parameters such as temperature, frequency, voltage-swing, power, or propagation time. These rules assure devices in the same logic family will work together when connected into a functional design. Standardization of logic families was facilitated in large part because of the limited number of market participants. Unlike in software, a high barrier of entry into the world of electronic device manufacture exists because the expense and expertise to create electronic devices is well beyond what any individual or small company can afford. The result is a few large and well-established companies dominate the market.
Electronic circuits, analogous to software applications, are constructed by connecting existing devices together in an order that provides a useful utility. The cost, efforts, and skill required to construct a circuit in this manner is many orders of magnitude less than that of constructing the actual devices, such as an Intel Pentium Processor™. By isolating the most complex job, such as the construction of a processor, into the domain of a very few highly skilled individuals, the industry is assured the rapid, high-quality construction of products that reuse the efforts of the most skilled engineers.
Unfortunately, there is a very low barrier to entry into the domain of creating computer programs, so no industry standardized logic family that would assure disparate programs could inter-operate without the need for programmers has been established. Thus, application development remains a slow inefficient process dominated by human error and competing standards.
Attempts have been made to solve these problems with the introduction of visually developed executable computers programs; however, many have failed to achieve the level of success as experienced in the electronic paradigm. Highly graphical development environments such as Microsoft's Visual-C++™ or Borland's Delphi™ have facilitated the creation of programs and applications, but at their heart remain programming environments requiring programmers to create and compile source code to do any but the most basic operations.
Visual connection paradigms have been developed to automate data flow between the properties of component frameworks that have metadata and support Run-Time-Type-Information (RTTI) and dynamic invocation, such as COM, or CORBA. A visual development environment may include an interface having a component inspector, component manager, component library, and one or more visual editors. A user can construct a program by selecting one or more components from the library, which displays components in a tabbed palette. Using a visual editor of the system, the user may drill-down into the internals of a component, for modifying its logic. Once the functionality of a component is completed, the user may proceed to connect together various components via the component “ports”, which allow access to properties of the component. Components of the system may be nested within other components to an arbitrary level.
Other visual approaches focus on creating named relations between classes in a dynamic object-oriented programming environment via mappers. The mapping objects dynamically bind to the class interfaces of the classes being related. These connections between classes are defined within a visual environment. The relationships can be programmatically attached by name to object instances during program execution. Because these relationships are stored in a resource and are dynamically bound by name to the objects, they can be created and modified without requiring the source code of the objects being associated to be changed. This eliminates hardcoded dependencies between objects that impede reuse of the objects in other contexts. This type of program requires meta-data, full dynamic binding and probing support in the objects being connected.
By operating in a completely generic fashion, these approaches are limited strictly to modern component frameworks, and further are limited to the static metadata, such as Run-Time-Type Information (RTTI), of components that cannot alter their behavior based on the run-time discovery of data; this relegates their usefulness to nothing but simple user interfaces. Most importantly, these solutions present numerous user steps to expose connections points between disparate programs and, though graphical and automated, are unable to access and operate dynamic data without programmer intervention.